Power management, intra-system communication, and many other peripheral functions in computer systems are often performed by serial and other secondary buses. Secondary buses generally include computer system buses, other than the main processor or system bus, which are often designed to accommodate a wide variety of secondary bus devices catered to particular user needs. As a result, it is advantageous for developers to have standardized interfaces which can accommodate many types of devices and system features.
Accordingly, bus protocols and compatibility requirements are often published in standard specifications, allowing widespread development of compatible devices. Such widespread development fosters the production of more interchangeable and compatible parts, ultimately benefiting consumers and allowing developers to confidently move forward with new products.
Widespread acceptance of a bus protocol also depends on the bus being flexible and having a robust feature set. Consequently, bus interfaces often sacrifice simplicity to improve the feature set and to allow future expansion. As a result, the overhead of implementing a compatible bus controller can be substantial for devices requiring only limited system interaction.
Numerous expansion and serial buses require non-trivial interfaces which represent significant overhead for certain bus agents. Some well known expansion buses include Industry Standard Association (ISA) and Extended Industry Standard Association (EISA) buses. Expansion buses typically provide a data, address, and control interface between a processor bus and the expansion bus. Some well known serial buses include the ACCESS bus and the System Management Bus (SMBus) which are based on a physical layer known as the Inter-Integrated Circuit (I.sup.2 C) Bus. Serial buses generally handle communication of system management information at a relatively low bandwidth.
In the serial bus environment, devices generally fall into the categories of master, slave, and host. A device which gains control of the bus and transmits information is a master device. A device receiving the transmitted information is referred to as a slave device. Each device may have both master and slave capabilities. A serial bus also typically has one host device which communicates with the computer system. This host device has an associated host slave port and host slave controller allowing the host device to receive commands from devices on the serial bus.
Expansion buses include master and slave devices; however, there is not typically a host device. Instead, a bus bridge typically transfers cycles between a system or processor bus and the expansion bus. Either type of system may suffer the shortcomings described herein.
The overhead of the logic required to interface with any one of these buses is most often problematic in slave devices which receive a small number of instructions. That is, where a slave device does not require elaborate control structures, the imposition of adding bus interface logic can be substantial. For example, a "smart" battery charger (i.e. one capable of interfacing with a computer system according to a particular bus protocol) situated on a SMBus typically only occasionally interacts with a smart battery or the computer system as power levels change. The system or the battery may request an increase or decrease in charging voltage or current due to voltage levels or battery temperature. For the charger, the bus control overhead can be significant since only a few power control signals are actually necessary to make such an adjustment.
In this simple slave device scenario, prior art host slave controllers fail to take advantage of already existing system hardware to simplify or eliminate other slave controller hardware. Such prior art devices either implement slave controller circuitry for each device or relegate that device to non-interaction with the bus. Additionally, prior art slave controllers fail to exploit a potential for debugging using the system processing power. This debugging cannot be done because the system lacks programmable registers which allow the capture and analysis of bus transactions.
In summary, some secondary bus devices incur significant overhead in complying with the appropriate bus protocol. These devices fail to utilize system processing resources which are already available and may adequately provide the necessary functionality. Consequently, situations are overlooked where emulation of bus interface logic using a computer system interface is more economical than designing a device compliant with the appropriate bus protocol.